![[レポート] あらゆるエンジニアためのコミュニティイベント 第3回 Hacker Tackle に参加して来ました #hackt](https://devio2023-media.developers.io/wp-content/uploads/2018/02/6a687b0958a42880799bf58f69fb9224.png)
[レポート] あらゆるエンジニアためのコミュニティイベント 第3回 Hacker Tackle に参加して来ました #hackt
はじめに
こんにちは モバイルアプリサービス部・サーバーレス開発部の田中孝明です
2/17(土)にLINE Fukuoka株式会社さまで HackerTackle が開催されました。
当ブログはセッションのまとめになります。
CONCEPT
HackerTackleは、プログラマのための総合技術イベントです。「ハッカー・タックル/博多・来る」の意味を持つイベント名には、多くのハッカーが博多に来て、さまざまな議論をぶつけあう場になればという思いがこめられています。イマのプログラマにとって必要な知識を切り取った、さまざまな技術に関するセッションを用意しています。
ぜひ博多に来て、新しい技術を吸収し、議論をぶつけあってみませんか？
スポンサーであるLINE Fukuoka株式会社さまのおかげで、ドリンクが飲み放題で提供されました。ありがとうございます！
Ponylangとこれからの並行プログラミング
デッドロック、データ競合など並行処理には様々な問題がつきものですが、幾つもの研究と経験からベストプラクティスが編み出されているのも事実です。 今回はこういった並行処理についての問題と一般的に用いられる解決策を述べるとともに、これらの背景の中で開発された新しいプログラミング言語Ponyを紹介します。 Ponyはアクターモデルをベースとしており、並行処理に関する様々なバグが存在しないことをコンパイル時に検証する強力な型システムを持っています。 v0.1のリリースが2015年4月と比較的若い言語ですが、安全性を保証するだけでなくパフォーマンスも追求した実装がなされており、これから並行プログラミングを行う際の選択肢になりうるポテンシャルを秘めています。 セッションではPonyが解決しようとしている問題だけでなく、言語設計で行われている様々な挑戦についても時間の許す限り紹介していきたいと思います！
株式会社FOLIO matsu_chara さん
PonyはActorモデルに特化した言語です。 複数スレッドのやり取りによる非決定状態、最適化のつもりでLockを細かくしたため、DeadLockが発生するなど、Concurrencyを実装には様々な難しさがあります。
Akkaなどで採用されている、アクターモデルは各アクターが独立して、メッセージによって処理を行うため、分散環境への対応も同じスタイルでかけるメリットがあります。
Zero-copyでmutableなデータを転送できることや、状態がImmutabeleなら共有しても安全なことなど、安全なアクセスであることが型で保障されます。
堅牢な型システムとそれによって得られる保証をフル活用したリッチなruntimeがPonyの長所とのことでした。
Concurrency in Rust (同時通訳あり)
The Rust programming language purports the bold claim that it guarantees thread safety while retaining the ability to write zero-cost abstractions. In this talk we'll explore precisely how Rust can make such a claim. We'll also explore the ecosystem that makes up the concurrency toolkit in Rust to see how these language principles are extended to common abstractions such as channels, thread pools, work stealing algorithms, concurrent data structures, and asynchronous I/O.
Mozilla Corporation Alex Crichton さん
- スライドは執筆時点で公開されていませんでした
メモリ関連については、以下のcode::dive 2017での登壇でも語られていますので、こちらも参考になります。
ムーアの法則の限界のより、CPUのスピートアップがこれ以上望めなくなってきました。 代わりにCPUのコア数が増加する傾向があります。
そこで並列処理を行いやすくする言語としてRustがあります。
並列処理を行う際にネックとなる、デッドロックや、メモリ解放忘れ、メモリ二重解放などをスコープで制御する機構が備わっています。 また、Concurrencyバグについては、コンパイラエラーで弾く機構も備わっています。 Rustはゼロコストでリソースを自動的に解放する仕組みを持っている、並列処理に特化した言語です。
確保したメモリは所有権（Ownership）によって、厳格に用途が定められています。
標準ライブラリの説明も行われました。
Atomically Reference Countedの仕組みを持つ
threadで安全にデータを共有する仕組み
Multi-producer, single-consumer FIFO queue
並列でイテレート処理を行うライブラリ
また、弊社の yoshihitoh が別途レポートを上げています。
無と型とプログラム
プログラムにおける「無」について考察します。 我々がコードを書くとき、「無」は至る所にあらゆる形で出現します。 未定義、初期化前、削除後、0、空文字列、空配列、etc...ひとたび表現を誤れば冗長なコードやバグに呵まされる事になります。 様々な言語における「無」の表現について、利点欠点を踏まえて紹介します。 また、どのように「無」を扱うべきなのか、直近で私が遭遇した「無」の取り扱いの失敗を参考に、「無」との付き合い方を考えていきたいと思います。
株式会社メルカリ tarunon さん
※UserNameを求められますが適当にxとか入れておけば見れますとのことです。
未定義、初期化前、削除後、0、空文字列、空配列や、プログラム中で実行されないことを保証することなど、プログラムには様々な形で「無」が存在します。
- Empty
空のオブジェクトを刺したりするが、基底クラスがEmptyだと、どんな型もEmptyに丸められたりします。
- Null
Emptyとは明確に区別できますが、あらゆる変数に対して、Nullかもしれない可能性をあたえ、アクセスすると、クラッシュしてしまう。
- Nullable
Nullの可能性がわかるが、ネストしたNullの存在、 T?? を表現できない。
- Option
Nullの可能性がわかる
重要なのは「NullとEmpty区別するのか、そもそも存在するのか」を考えながらプログラムを書くことです。
Apache Hivemall meets DigDag: Machine Learning Pipeline in SQL queries
Apache Hivemallは、日本発のOSSプロジェクトとして初めてApache Software Foundationで育成プロジェクトとして認められ、トップレベルのASFプロジェクトへの昇格を目指して開発を進めています。 機械学習の特徴量エンジニアリングや各種学習アルゴリズムをユーザー定義関数（UDF）として実装することで、機械学習の一連の処理をHiveQLやSparkSQLなどSQLクエリによる実現できるのがApache Hivemallの最大の特徴です。 本講演では、前半でHivemallの機能の紹介をし、後半でトレジャーデータが開発するOSSワークフローエンジンDigDagとApache Hivemallを利用した機械学習ワークフローの実例を紹介します。 ワークフローエンジンとの組合せにより複雑な機械学習ワークフローをどのようにプロダクション環境に展開したら良いかの一例を示します。
トレジャーデータ株式会社 油井 誠 さん
Hivemallについては、T-mobile、kloutで使われています。 minneのアイテムレコメンドサービスや、イエシルさんでも。
オイシックスさんでは離反しそうな人をケアフォローするなど。
簡単に使えて、スケーラブルで多目的に使えるマシンラーニングです。 SQLをかけるようなエンジニアに機械学習をつかってもらうことが可能です。
ML workflow uging DigdagはYAMLでワークフローを作れるので、コードベースで管理できます。
Docker Imageがあり、シングルノードだとすぐ試せるので、とりあえず使ってみたいという方にもオススメです。
人工知能の研究者は今なにがアツいと思っているのか
人工知能といってもその捉え方は人によって様々です。 今で言う「人工知能」を大雑把に捉えるなら、ひとつは「機械学習」、もうひとつは「汎用人工知能」です。 前者は近年のディープラーニングブームによってエンジニアのみなさんにとってもすっかり身近なものになりました。 後者はというとOpenAIや全脳知能アーキテクチャが目指している「人間のような適応能力を持つ”真の”人工知能」ですがこちらはまだ一般的なものではありません(巷では2045年には実現してシンギュラリティが起きるそうですが……！)。 本セッションでは両者の進展を交えつつ、特に後者の汎用人工知能研究において、最前線にいる人々が一体なにを考え、どのような問題にどう取り組んでいるのかについて紹介します。
株式会社ウサギィ 五木田 和也(ごきた かずや) さん
- スライドは執筆時点で公開されていませんでした
人工知能ブーム・機械学習ブームと言われているが、ディープラーニングなどの、ごく一部しか流行っていない
Artifiacial Interllinstingで生き物の知能を再現する
MITがAGI専用のオンライン講座を始めたり、Deep MindもAGIについて割と考えている
機械学習研究が盛り上がって知見も増えてきている
ただし、本来瓦礫を乗り越えたり、車から降りたりするタスクは人間では難しくないが、機械では今だに実現しづらい状況である 人間にとって難しい問題は機械だと簡単に行えるが、人間にとって簡単なものが難しい。
工学的な意味でも、脳の手法を真似できたら良さそうだ。
大脳基底核はほぼ強化学習をしていると考えられている。 報酬を予測し、報酬が最大化されるとうにしている。
小脳はどの動物でも同じ構造 ニューラルネットワークに近いと考えられている（小脳パーセプトロン仮説）
大脳新皮質は思考の中枢だが流石に難しい Deep Learning多層ニューラルネットワークの成果は活かせているがモデルも謎
最近のアプローチとしては、脳はなにかの最小化問題を説いていると仮定し、その問題さえわかれば脳の構造とかはあまり考えなくて良いのではというところになっている。
身体性が必要、ということでロボット系になるのだが、脳科学と情報工学の距離がまだ遠いとのことです。
ディープラーニング専用ハードウェアの研究開発について
近年、組込みデバイスにもディープラーニングを取り込む動きが活発になってきており、特にFPGAはその書き換え可能性を活かすことで、アルゴリズムの進化に対応しつつ、低消費電力かつ高性能なディープラーニングを実現できるデバイスとして注目を集めています。しかし、アルゴリズム・GPU・数学的な背景を駆使して学習を行い、かつ、組込み機器を熟知してソフト・ハードと連携した推論を実装する技術が必要であり、実装難易度が高い状況です。私たちの研究グループでは、ディープラーニングの学習・推論を同時に開発できるGUINNESS (GUI for a Neural Network SyntheSizer)を開発しています。GUIベースの開発環境なので、Python, C++, HDL等の設計は必要なく、ニューラルネットワークの設計に注力でき、ソフトウェア技術者ユーザでもFPGA実装が可能です。今回は物体認識をFPGAに実装した事例を紹介します。
東京工業大学 中原 啓貴 さん
AIの普及で、機械学習の組み合わせが増えてきた。 その中でもエッジデバイス（組み込み機器）でディープラーニングを動かす要件もでてきた。
クラウドにモデルを置くと発生する様々な問題を解決するために、学習の終わったモデルをデバイスに組み込む。 そこには、スピードと電力のトレードオフが発生する。
アルゴリズムは日々進化しており、ハードウェアを作成していたら間に合わない。 そこで、FPGAを活用する。
GUIベースで、GPUのトレーニングとFPGAのbitstreamを行うライブラリ GUINNESS を作成されています。
Beyond the Debug: テスト、デバッグ、その先の技術へ
様々な開発の現場ではテストをしたり、レビューを行うのが一般的だと思います。 しかし、それらの品質活動を行う際に相手となる「バグ」とはなんでしょうか？バグを説明したり図示したり、そもそも感覚的なバグの対処は、医学で言えば病気を知らずに治療する医師と同種の行動に他なりません。 本セッションでは、バグにタックルします。 問題は１）バグの定義が存在しないこと、２）バグの表現方法がないこと、３）バグの検出方法が一定ではないことの３点です。 これら問題に対して、本セッションでは欠陥の定義スキーマ、欠陥モデル、欠陥兆候因子の検出技法などを説明した上で、これを機械学習を用いて自動的なバグの分析・分類方法についてもデモを交えて解説します。 次から次へと生まれては消えゆく先進開発技術を追いかける前に、現在までに経験したバグを後世に残すこと。 これが次世代に輝く技術者が最も注力すべき「財産」構築だと考えます。 全ての未来の技術者の一助の考となれば幸いです。
日本IBM 細川 宣啓 さん
- スライドは執筆時点で公開されていませんでした
コードレビューなど、本来は行いたくない作業。
そこで、過去に出たバグをモデリングして持つことができないか検証されているとのことです。
医学的なアプローチでソフトウェアの欠陥を捉え、観察データに基づく仮説推定、モデル照合によるパターン認識・チェック環境因子から過失誘発を予測し、医学であるような治療のアプローチをコンピュータに模試していくことで使えるようになるまで研究されています。
人間の体がウィルスから防衛するメカニズムを応用し、バグを抽象化する。
バグ分析の人工知能化を行なっている。なぜなら、区別分別は機械学習の得意分野であるから。
そこで、人体の免疫システムを参考にしている
- 自分じゃない物質を認識
- ヒスタミンでマーキングする
- マクロファージが突入して病原菌に張り付き
- 無毒化する技術
これらをソフトウェアの品質として応用するため、人工知能を利用しています。
Scrumが難しいのは幻想-情熱の再定義-
私達のチームは2016年までメトリクスの活用、スプリント期間の短縮、くじ引きで決めるPOやSM、などのプラクティスを通して改善を繰り返してきました。 スクラムガイドもどんどん破りました。 このチームはScrumが難しいなんて思っていませんし、誰でも出来ると信じています。 チームが開発する製品は大きく変わりましたがScrumが難しいなんてことはありませんでしたし、なによりこのチームのエッセンスを大学生40名に導入したところなんと1週間で1日スプリントをモノにしました。 Scrumが難しいのは幻想だったのかもしれません。 我々のチームはこういったことを通して2017年にいくつかのプラクティスを確立しました。 スプリント期間は1時間へ、チーム内ボトルネックへの対応時間は25分以内を保証、人的リソース活用の損益分岐点を常に意識できる開発プロセスです。 結果、1週間でレビューを35回以上、振り返りを30回以上行っています。 1週間で改善した項目は最大で20アイテムにおよび、それらのムダ取りによって6ヶ月間で最大2倍の成果を生み出しています。 チームのパフォーマンスを最大化するために私達の計画的な学び方、偶発的事象からの学び方などをScrumの文脈でご紹介します。
きょん さん
POの仕事の大部分を情熱に片付けるのはどうなのか、では情熱とは何か、情熱を再定義しよう。
いままでのスクラムへの取り組みとしては、スクラムガイドを徹底的にやり直す、ユーザーガイド駆動、1日ごとにPOを指名したりしてきた。
また、学生40名くらいにスクラムを教えた。 彼らは1週間で1日1スプリントを達成した。
PDCAの前に共感が大切。 POも一緒になって課題にぶつかって、苦しんで一緒に課題を観察して、チームと苦楽を共にしないと、POの言葉にチームは共感しない。
そこで、1Hour Sprintを行うようにした。
専用プロジェクトルームを用意し、短いスパンでレビューと計画を行い、ゴールを見失って開発を進めてしまうことをなくした。
掲げるのは超個体の挑戦。 ゴールのために自分の作業をすべて捨てること。
情熱という言葉の排除し、特異点を発生したら特定の行動をする。
情熱とは
- 高速なプロトコル変換
- リアクティブシステム
- 監視
タスクはできるひとがやるで良い、多能工になればいいし、できなければ一緒にやればいいペア作業をすればいい。
Apache Geodeで学ぶ！インメモリーデータグリッド
これからのシステムアーキテクチャに必要なのは超高速でスケーラブルなデータアクセス。 それを実現するのがインメモリーデータグリッドです。 今回はオープンソースの「Apache Geode」を使ってマイクロサービスアーキテクチャー、CQRSアーキテクチャーに最適なデータ処理の実装方法をjava.util.Mapと比較しつつご紹介します。
ウルシステムズ株式会社 山河 征紀（やまかわ まさき） さん
マイクロサービスで、JDBCを使っていると、インピーダンスミスマッチが発生することがある。O/Rマッパーが出て楽にはなったが、型があってないなどの問題は発生する。
そもそもDBがいるのか？ DBがなくなるとO/Rマッパーもいらない。
メモリーの中のオブジェクトの共有ができれば不要。
インメモリーデータグリッドという、複数のサーバーを束ねて一つの仮想的なメモリー空間を作り出す技術をつかった。
データを各サーバーのメモリー上に分散保持してくれ、java.util.Mapを使用している感覚でデータが利用できる。
リアルタイムキャッシュが使えるので、サーバー側での変更があれば最新のデータとなり、常にメモリ中のデータが最新であると判断できる。
OQL（Object Query Language）ができるので、データが多い場合はパラレルクエリーも実行できる。
Pub Sub型のサービス連携により、自分が興味があるイベントをsubscribeすることで、データが登録されると、イベントが発火する仕組みがデフォルトで備わっている。
まとめとしては
- インメモリで速い
- 読みこみ、書き込みとも、スケールアウトできる
- 柔軟なイベント処理ができる
- マイクロサービスやCQRSで使いやすい
はてなにおける機械学習の取り組み
機械学習を使ったアプケーション開発は技術的負債の高利子クレジットカードと言われることもあり、技術的負債になりやすい存在です。 はてなでも、これまではてなブックマークの記事カテゴリ判定などの様々な場面で機械学習を活用した機能を開発してきましたが、中には、モデルの再現や継続的な改善ができず技術的負債となってしまった機能も存在します。 こうした課題がある中、教師あり機械学習を使ったアプリケーションであり、Perlで書かれていたBrandSafeはてなをPythonでリプレースしました。 BrandSafeはてなを事例として、機械学習システムを技術的負債にしないために、機械学習を使ったアプリケーション開発時に考慮した機械学習の再現性や、データやモデルのバージョン管理についての取り組みを紹介します。 また、はてなではこれまで経験のなかった教師なし機械学習(異常検知)を利用したアプリケーション開発を行なう際に組織で行なった取り組みも紹介します。
株式会社はてな 吉田 康久 さん
機械学習を使ったサービス開発で、その難しさを乗り越えていくための技術的組織的な取り組みを話されました。
はてなでは、はてなブックマークのカテゴリ判定、エリアガイド、Mackerelの異常検知などに機械学習を利用している。
機械学習をつかったサービス開発の難しさとしては、挙動の把握が難しい。 プログラムはコードを見れば挙動の把握はできるが、機械学習はコードのみからは挙動の把握ができない。 コードxデータがあれば、挙動の推測は不可能ではないが、知識と経験が必要。そのため、属人性が高く、作った人の研究結果として残ってしまう。また、再現性が低い。
その難しさを乗り越えていくための技術的な取り組みについてBrandSafeはてなリニューアルをベースに話されていました。
- 調査フェーズ
課題の性質を明らかにする 絶対数の多い障害パターンは？ 障害の要因は？
- プロトタイプフェイズ
典型事例だった障害に対して、さまざまな方法をひたすら試す
- アルゴリズム決定フェイズ
レビュー可能かどうか
組織的な取り組み方としては
- 各サービスに機械学習に詳しい人物がいても1人か2人
- サービス横断の機械学習会を設立
- Perl / Scala / Pythonによるお手本実装
機械学習会のメンバーで回答レビューを行なって、機械学習の属人性を排除していったとのことです。
全然わからない。俺たちは雰囲気でコンテナをやっている
皆さんは、やっていますか？ コンテナなどを...。 運用自動化やInfrastructure as Codeの隆盛などから、さまざまな文脈でLinuxコンテナに注目が集まっています。 そんなコンテナに関するキーワードは、LXCに始まり、Docker、runc、Kubernetes、OCI、CRI-O、果ては各種クラウドまで拡散し、枚挙にいとまがありません。 本セッションでは、あまりに早い潮流の変化に置いていかれているような感覚を覚える方、触れてはみたものの根本的な技術の理解が追いつかない技術者のために、 コンテナ技術を上から下まで眺めて、整理することを試みます。 その上で、Kubernetesだけではないコンテナの活用の一例として、拙作「Haconiwa」を使って何ができるか、何をしているかのお話もできればと思います。
GMOペパボ株式会社 技術基盤チーム 近藤 うちお さん
雰囲気で使っていたコンテナの中身を理解するための話をしていただきました。
コンテナで実行したSleepコマンドはプロセスからも見えることから、コンテナの中身は特殊なプロセスであることを理解し、CPUやメモリなどの仮想化は行なっていないことに注意しましょう。
OCIというコンテナの色々な規約・企画を標準化している団体があり、コンテナ用語や、各コンテナについて、解説されています。
コンテナの概念モデルは極めて簡素化された「あるもの」がどう動くか説明されており、コンテナを、ハイパーバイザー型のものと勘違いして使っているのではなく、中身を追いかけて理解することが需要とのことでした。
実践！スタンプ屋さんの開発運用
みんなでスタンプを仕入れて売って暮らしています（意訳）。 しかし商品も多く、お客さんも多く、24時間営業のお店の店番は大変です。 このセッションでは、あくまでも実践の共有として、我々のサービスの開発運用でぶつかる課題や、例えばどのようなことができるか・しているかというトピックを安定してサービスを開発し運用する両面の観点で紹介しようと思います。 新しい機能の開発からリリースまで、稼働しているサービスのモニタリング・トラブルシューティングなどを可能な範囲で具体的に紹介します。 これがベストプラクティス、という話より、問題意識と今の現実、あと少しの理想の話題です。できれば皆さんとも意見交換や議論などができましたら嬉しいです。
LINE株式会社 佐藤 春旗 さん
Googleの SER LIKE APPROACHESにそって話されていました。
スタンプはLINEのコアなサービスにも関わっています。
Github Enterpriseを契約していますが、チームではシングルリポジトリで関連するモジュールも管理しています。
一つのリポジトリを使う利点として、定義を簡単に共有できる、リリースのやりかたがシンプルになるなどが挙げられます。
リリースはリリースブランチを作ってリリースし、ウィークリーでリリースしています。
木曜日にブランチを作成し、ステージングにデプロイし、１週間かけてレグレッションテストします。 細かくリリースしていくことで、まだリリースされていない機能というのをなくすようにしています。
モバイル側でもそれを踏襲しているとのことです。
スポンサーセッション
LINE Corporation KYOTOの和田さんから採用について話され...ると思いましたが、Erlangのメモリ管理について他の言語との違いも踏まえて解説が始まりました...!
LINEでは、そういう話が日常的に行われている職場とのことでした。
懇親会
懇親会では、登壇者、運営の皆様、参加者を交えながら、軽食をつまみながら意見や議論をぶつけ合う機会が提供されました。
また、主催者の松崎さんときしださんが誕生日を迎えられるというサプライズもありました！
まとめ
おそらく東京などでもこんなにマニアックで濃密なセッションを行う勉強会はないと思います。
登壇者の皆様、運営の皆様、本当にありがとうございました。
各分野で普段絶対に接点のないトッププレイヤーのみなさまから貴重なお話がいただけたので、非常に充実した1日となりました。
来年は県外の皆様も是非、福岡観光も兼ねていらっしゃってはいかがでしょうか？
